home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / cpp_libs / awe2-0_1.lha / awe2-0.1 / Documentation / Post < prev    next >
Text File  |  1989-04-03  |  3KB  |  56 lines
  1. In-reply-to: prl@iis.UUCP's message of 2 Apr 89 15:20:02 GMT
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Some problems in the task class
  4. References: <810@eiger.iis.UUCP>
  5. Distribution: 
  6. --text follows this line--
  7.  
  8. I'd looked at the AT&T Tasking library & came to basically the same
  9. conclusions that you did. It's a mess, and it's more of a mess than
  10. you might suspect.
  11.  
  12. Consider porting to a compiler that doesn't require frame pointers for
  13. procedure (Greenhills on the 32K, Gnu CC on everything). All of a
  14. sudden, you find yourself copying *huge* stacks for what might be a
  15. couple of arguments.
  16.  
  17. Also, adding the task to the scheduling list in the constructor for
  18. the task class is a pain. In multiprocessor environments, it leads to
  19. a parallel-unsafe implementation: one processor can be executing
  20. subclass constructors while another pulls the task off the queue to
  21. execute.  Bogus.
  22.  
  23. I wrote another tasking library that has a class Thread. Constructors
  24. to a thread are simple constructors, nothing more. You pass arguments,
  25. save what you need, compute what you need, etc.
  26.  
  27. A thread must be explicitly enqueued to a queue (typically, one
  28. maintained as ``ThisCpu'', the abstraction for the current processor).
  29.  
  30. All threads have a virtual void function called ``main''. When a
  31. thread is invoked for the first time, execution ``magically'' starts
  32. by calling the ``main'' function. When you exit ``main'', your thread
  33. kills itself.
  34.  
  35. The context information for a thread is stored in another class,
  36. called a HardwareContext, allowing some seperation of the thread
  37. information and contexts. Things other than threads (e.g., the actual
  38. unix processes managing the threads) have contexts.
  39.  
  40. This has worked fairly well. It runs on Sun-3's & the Encore multimax.
  41. I've written a library of C++ objects that implement either a
  42. SingleCpu or a MultiCpu scheduler. There are subclasses of the Cpu
  43. objects that that implement global-time process-oriented simulation.
  44. There are SpinLocks, SpinEvents, SpinBarriers, Semaphores, Events,
  45. Barriers, and Facilities. The entire package gets a fair bit of use
  46. here, because it's used for simulation.  Someone is also using it as a
  47. simple multi-tasking library for the Encore multimax for a parallel
  48. C++-scheme interpreter.
  49.  
  50. There are some complications that eventually need resolving, probably
  51. when G++ gets M.I. working. Somethings would be easier if
  52. delegation-via-pointer was available.
  53.  
  54. Eventually, the whole kit-and-kaboodle will be available, probably
  55. through Gnu Libg++.
  56.